\chapter{Justifications}
\ifpdf
    \graphicspath{{Chapter2/Chapter2Figs/PNG/}{Chapter2/Chapter2Figs/PDF/}{Chapter2/Chapter2Figs/}}
\else
    \graphicspath{{Chapter2/Chapter2Figs/EPS/}{Chapter2/Chapter2Figs/}}
\fi

\section{Using Python as the programming language}

\subsection{Expressiveness}
The process shown in the flowchart is quite complicated, and most steps in the process are not performance intensive. Therefore, we would like to be able to work in an environment where we can rapidly prototype both known algorithms and our ideas. Python is known to be much more expressive than other alternatives. 

\subsection{Interactivity}
Since Python is an interpreted language, we are able to run our programs interactively, with the freedom of making modifications while running.  This was a very helpful and commonly used technique during the design process. A common scenario goes like this:

\begin{itemize}
 \item {Part A of our program finished running for the first time}
 \item {We get to Part B of this program that was never executed before}
 \item {Part B has a bug in it}
 \item {We fix the bug and continue}
\end{itemize}

This would not be possible with compiled language unless we save all our intermediates results in files, which introduces considerable overhead.

\subsection{Numerical Package}
Good OpenSource numerical and plotting packages like NumPy, SciPy and matplotlib are avalable for the Python language. This project involves tons of numerical computations.

\subsection{Extensibility to GPU}
If our core code are written in Python, we can easily substitute the NumPy package used by GNumPy. The code can then be ran on a GPU, which offers a speed improvement up to 30 times. GNumPy \cite{gnumpy} is based on CUDAmat \cite{cudamat}, which is in turn based on CUDA.

\subsection{Familiarity, OpenSource and availability of support}
Finally, there are possibly other languages that are expressive and have nice numerical packages such as MATLAB, C++, Java etc. Python is separated by the following important attributes.
\begin{itemize}
 \item {people in this team are familiar with Python}
 \item {Python is OpenSource and has a global standard}
 \item {many people use the language so it is widely supported}
\end{itemize}

\section{Using OpenKinect as driver}
In the current market, there are two primary Kinect open source drivers: libfreenect and OpenNI. In order to choose the driver that best suits our needs, here is a list of requirements that the chosen Kinect driver must support:
\begin{itemize}
 \item {Python wrapper}
 \item {Control the tilting motor}
 \item {RGB data callback}
 \item {Depth data callback}
 \item {Run on Linux}
\end{itemize}

Both drivers meet the requirements listed above, however at the time of our initial research, python wrapper was not available for openni. In terms of functionalities, OpenNI provides a rich set of middleware features such as full body analysis, gesture detection and hand point analysis that are outside of the scope of this project. Although, it can be helpful to have a rich set of external libraries, but it also affects the portability of the final software. Overall, libfreenect was chosen over OpenNI, for its simple design and its support for Python \cite{pythonwrapper, OpenNI}.

\section{Meshing}

 The general problem of converting a point cloud to a mesh model is thoroughly studied in the field of computer graphics \cite{rendermesh} \cite{ptcloudmodel}, as there is a number of third-party software available that we could use to perform this operation. In order to choose which application is the most suitable for this project, here are the requirements and criteria that we used for our selection process:
\begin{itemize}

\item{Performance: It is critical that the final mesh closely resemble to the input point cloud in terms of physical dimensions and also color coating. Moreover, there are some noisy data from the point cloud such as layer overlaps that the software should adjust and ignore.}

\item{Time: The whole process time should be fast and comparable with the timing of the other components. We don’t want this step to be the bottleneck of the overall flow.}

\item{Cost: The whole aim of this project is to make a cheap 3D scanner. Hence, if free open source software can handle the job reasonably well, we don’t want to waste money on commercial software.}

\item{Automation: The whole process should be automated. Ideally, we want to write a shell script to execute the whole operation. The script specifies the input file in a point cloud form and the output should a 3D model file in the corresponding mesh form.}

\item{Platform: So far, all the implementations are done on Ubuntu Linux machines. Hence, Linux based programs are preferred.}

See \ref{chap:meshsoft} for a detailed comparison between different meshing softwares. MeshLab was chosen as the best fit for this project. 
\end{itemize}


\section{Using the PLY file format}
The RepRap official website provided three “recommended file formats” for representing a 3D object: STL, PLY, and COLLADA \cite{recformat}. 

The STL (StereoLithography) format is a commonly used file format for 3D prototyping. A STL file is simply a list of triangles that the object is composed of. No colour or texture information is stored. \cite{stl}.

The PLY polygon file format is a simple portable file format between different design tools. It breaks the 3D object into multiple polygons, and stored the information of each polygon in a list. On top of the vertices and surface normal vectors that are supported by STL format, PLY format can also store colour, transparency, texture information, and even user customized variables.

The COLLADA file format is intended for lossless information conversion between different 3D design software. It defines a XML schema for all object attributes across multiple 3D design programs and a COLLADA file is simply a XML file that follows the schema. It supports much more properties that a PLY file does, such as curves and animation \cite{ply}.


All three file formats are supported by MeshLab and other major graphic processing programs, so they are all portable formats. Because a triangle is basically a 3-edge polygon, the PLY format is a superset of STL format. PLY can store all required information specified in the requirement, while STL is missing the color information. As a result, PLY format is preferred instead of STL. The COLLADA format is much more complicated than PLY but the extra information it supports is beyond the scope of this project. Since PLY already provided all required information, there is no need to use the COLLADA format which will make the programming work much harder to implement. As a result, the PLY file format was chosen as the official output format \cite{collada}.
 
\section{Combination Method}
A large part of the combination algorithm is based on published works \cite{3drecon, nonrigid}. After making several important modifications inspired by \cite{nonrigid} and based on \cite{3drecon}, the algorithm generally works well. Runtime can still be quite long, and scales quadratically with the number of points sampled. The final algorithm takes between 10 minutes (for 1000 points sampled) and 5 hours (for 5000 points sampled) on a i7 2.5GHz computer.  This amount of time is negligible compared to the time needed to print the object (11 hours on RepRap). On the other hand, the algorithm is highly parallelizable, and can almost be made n times faster if ran on n processors. The exact algorithm published also had similar performance characteristics.

We also tried a Bayesian model using Markov Chain Monte Carlo for inference, the performance is even worse. See Appendix \ref{chap:comb} for more information.
% ------------------------------------------------------------------------

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "../thesis"
%%% End: 
